package tg.loader.test;

/**
 * 游戏定义注解
 * @author NKW
 * 数据库里游戏绑定的类，需要实现游戏接口
 * 底层框启动游戏，并初始化参数
 * 提供数据库dao访问层
 * 
 * 游戏额度如何加减？ 后台管理的【充值提取】和会员的【下注中奖】这两边得同步的
 * 
 * 结算时   会员单个人 事务结算（注单更新到库的字段要最少才能加快速度，最好能灵活配置多个会员结算一起事务提交，以加快速度，单个可能会慢），  结算所有会员之后再调用过程进行报表生成
 *
 * 额度不用统一内存管理，通过数据库来同步，  尽量每次都一次性交互，在过程里实现额度的加减，第一句先select加updlock查询 回来判断可以后再操盘（如果是加可以不用，直接更新）
 *     最好一次性提交到数据库：用存储过程来实现，在update额度后同时把新额度取出来（不用再select)，一次性完成可提高效率,一次select一次判断一次更新（最后不用select,update后可以取新值)
 *     最好用聚集索引id来查找更新账户，这样速度最快 
 *     缓存的只是为了看，偶尔不同步没事，真正在数据库都会再查询 后操作，成功失败都会返回最新值再更新内存，最后再提示成功失败
 *     但是缓存不可能每次都从数据库取，所以如果有更新还是要通知缓存及时刷新最新余额
 *     
 *---------------------------------------------------------------------     
 * 充值提取（转账）：
 *    上级，下级，额度（不管正负） ,同个人之间的账户间也是可以转账的
 *    开启事务
 *       执行【上级】额度变化过程：
 *          更新余额  -- 同一语句可以取出新旧值，刚好生成上级流水记录
 *          根据新旧值判断是否成功
 *          	成功：插入上级流水记录（充值提取类型）
 *       			执行【下级】额度变化过程：
 *          			更新余额  -- 同一语句可以取出新旧值，刚好生成下级流水记录
 *          			根据新旧值判断是否成功
 *          				成功：插入下级流水记录（充值提取类型）,提交事务
 *                          失败：下级余额不足，回滚事务
 *          	失败：上级余额不足，回滚事务
 *    结束事务
 *    返回上级、下级的最新余额
 *---------------------------------------------------------------------  
 * 下注：
 *   余额不判断
 *   其他判断过后：创建好所有下注单，本人[普通注单]和上级[飞单]
 *   开启事务
 *       执行单人额度变化过程：
 *          更新余额  -- 同一语句可以取出新旧值，刚好生成流水记录
 *          根据新旧值判断是否成功
 *          	成功：插入流水记录（下注类型）
 *       			插入所有注单【下注单和飞单】
 *       			提交事务
 *              失败：下注人余额不足，回滚事务
 *    结束事务
 *    返回下注人最新余额
 *---------------------------------------------------------------------  
 * 下注人结算：
 *    内存中会员所有注单结算，统计总派彩
 *    开启事务
 *       更新所有注单  -- 只要更新几个关键的字段
 *       如果本会员派彩大于0
 *      	 执行单人额度变化过程：
 *          	更新余额  -- 同一语句可以取出新旧值，刚好生成流水记录
 *          	插入流水（派彩类型）【只有加，所以不可能不够，根本不用判断】
 *    结束事务
 *    返回结算人的最新余额
 * >>>>>>>>>>>>>>>>>>>>>>>>>后记   
 * 下注人注单结算完之后，在数据库执行对所有注单计算生成报表过程就是结算下注人的上级代理商（下注人也有可能是代理商的）
 *--------------------------------------------
 *             下面是【报表】和【注单明细】
 * 报表表也用天来做分表单位
 * 注单明细也用天来做分表单位
 *    当每期结算完都创建【期数报表（玩法为基本单位，可以分类报）】
 *    当天结束时间点到时  创建  【天报表（玩法为基本单位，可以分类报）】 ，天结束同时判断周、月：
 *       当周结束时 创建 【周报（玩法为基本单位，可以分类报）】 
 *       当月结束 时创建【月报（玩法为基本单位，可以分类报）】
 *    如果要查多天时，用天报表来 john或合并到内存表再查询出来，加个指定跨天的天数限制，以方便控制服务负载
 *    
 * 注单明细只能会员级查询，并且如果不是天范围的，再多一级显示 【天】或【游戏】，再让用户选择哪一天或哪个游戏的明细，只能具体天哪个游戏哪天哪期的下注明细，这样效率是最高的
 * 
 * 报表记录上的各级字段结果是  上级设定在下级上面的结果，是上级看下级的，上级看我的下级在我的设定下的输赢
 *
 *-----------------------------------------------------------------
 *--------------------------------------------
 *             下面是  【额度】
 *
 *
 *
 *-----------------------------------------------------------------
 *--------------------------------------------
 *             下面是  【币值】
 * 1.币值 只是显示给各级人员看的
 * 2.在下注人下注时，把下注人币值 往上级累加时，每个上级都换算成本级的币值 来累加，每级的值 是自己的币值 的值 
 * 3.每级的设定的数值都是上级的币值，下级要查询上级给我的设定时，需要转换成下级的币值 
 * 4.下注和报表中要记录当时的汇率，不然过后汇率改变时再查会不一样
 * 5.报表生成时，是用会员的各级输赢求和，所以要用会员的当时汇率来转换成本
 *
 *
 *-----------------------------------------------------------------
 * 额度不需要在内存判断 ，直接调用数据库来实现，让数据库来同步，内存中可以让额度不够时，要指定间隔后再到数据库来尝试，因为需要充值时间
 * 内存的额度只是参考用，但是也要有接口可以强制从数据库刷新
 * 
 *同一游戏类型，它的额度绑定肯定是一样的，所以直接用游戏类型绑定额度类型
 *
 *定义额度类型表，（不同类型都有两种返还类型【信用】【现金】）
 *
 *定义出来的额度类型在信用时要加定义返还周期（一般是一天，而且要指定周期内的返还时间点，比如每天10点）
 *
 *每个游戏类型的属性里面都绑定 额度类型
 *
 *游戏下注和派彩时都根据绑定的额度类型来对会员的账户扣分和派彩
 *
 *币值 和额度类型关系不大
 *
 *币值 只是在报表时换算出来当前代理商的币值 来看
 *
 *而且币值 在 下注后累加到上级时，每级的实盘虚盘都需要换算成自己的币值累加，用自己级的货量来飞单和自动降倍
 *
 *币值最后优化设定时，可以加模块设定来解决开下级时，设定值 用币值 转换带来的小数问题，或者设定规则 来解决，当前用默认1来都不会变
 *
 *报表要生成周报，月报，
 *  报表也按天分表，查不定区间时，可以限制 区间大小，用查出来的天报表再后再合成区间报表，应该不影响效率
 *报表要做好优化  每期>每天>每周>每月
 *
 *-----------------------------------------------------
 *游戏提供服务
 *   提供统一服务接口，具体游戏自己再去解析，一般游戏状态自己来查询：查询游戏中的各种信息，最主要查询 游戏状态，  提供下注服务
 *   	服务是
 *   提供给游戏加载模块提供广播通知中心服务，用来通知本游戏用户游戏状态变化，开奖这类会通知的比较及时，真人游戏中的结算也最好用通知
 *   
 * 彩票游戏可以一条件轮询通道包含所有的信息：
 *    余额变化信息，游戏状态变化信息（包括开奖变化），跑马灯信息变化（各游戏跑马灯和大厅跑马灯），公告信息变化（重要的通知，可以指定对象范围）
 *    页面赔率变化信息（会员端），页面操盘变化信息（代理端下注和赔率变化）-->到时页面要注册，用页面id来访问，玩法id会比较长，不过有优化过的id倒是可以
 *    这些信息都有最后更新时间， 前端初始会拿-1来取，所有都信息第一次都会取回去（只要有一个取走，后台当前 时间就是前端的最后更新时间），以后每个信息的最后更新时间
 *    都和来取的时间比，如果是更新的，都取回去，只要有取一个以上，后台的最后时间都返回给前端当做最后取的时间
 *    
 *   
 *
 *这里是游戏类的注解定义，这里定义的游戏类，绑定到数据库，桌子根据绑定的游戏，创建游戏实例来运行
 */
public @interface GameAppDefine {
	/**  
     * 游戏id
     * @return  SSC
     */    
    String gid() default "";  
    /**  
     * 游戏名称  
     * @return  
     */    
    String name() default "";  
}
